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(57) Abstract: The invention proposes a method for handling connection information in a communication network, comprising the 
steps of intercepting a data packet sent from/to a target (SI), extracting a header of the intercepted data packet (S4), and sending the 
extracted header to a monitoring entity (S5). Instead of extracting the header and forwarding it, the method may alternatively com- 
Q prise the steps of examining the intercepted data packets with respect to specific information, determining whether an predetermined 
£^ event with respect to the specific information has occurred, and, if the predetermined event has occurred, sending a corresponding 
^ message to a monitoring entity. In this way, a more flexible handling of connection information is possible. 
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METHOD AND SYSTEM FOR HANDLING CONNECTION 
INFORMATION IN A COMMUNICATION NETWORK 

The present application claims the benefit of priority of Provisional 
Application No. 60/426,382, filed November 15, 2002, the 
5 contents of which are incorporated herein by reference. 

Field of the invention 

This invention relates to a method and a system for handling 
connection information in a communication network. 

io Background of the invention 

In particular, the invention relates to lawful interception within a 
communication network system which includes one or more 
network entities like a GSM/UMTS system or method. 

15^ Lawful interception of telecommunications is required by law in 
most countries. See Table 1 for classification of currently collected 
interception data. In packet switched GSM and UMTS networks 
lawful interception considers binary data exchanged between a 
mobile station and an access point. More specific, the SGSN 

20 and/or GGSN network elements in GRPS/3G core network collect 
the exchanged data on the request of an ADMF, and send it to DF 
that forwards the data to a lawful enforcement monitoring facility 
LEMF. 

25 The following table 1 illustrates currently collected IRI and CC 
data in Circuit switched and Packet switched environment. 

CONFIRMATION COPY 
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IRI 


CC 


Circuit 
switched 

"i, 


B source of the call 

■ destination of the call 

■ location of the caller 

■ length of the call 

■ type of the call 


■ content of the call 


Packet 
switched 


■ target's IP address 

■ location 


■ content of the connection 
containing 

■ source and destination 
IP addresses 

■ length of the exchanged 
data 

■ type of the connection 



Two types of interception data are collected. The interception 
related information IRI contains signalling information such as the 
start and end of a PDP context, for example. On the other hand, 
5 the contents of communication CC contains the actual user data 
exchanged, say IP packets from an e-mail. An LEA obtains an 
authorisation to intercept IRI more easily, in order to intercept CC 
more grave accusations must be the case. 

10 Packet switched IRI data differs significantly from circuit-switched 
IRI data, see Table 1. In circuit switched environment, the called 
party as well as the length and type of the call are included to IRI 
data. In packet switched environment the source and the 
destination IP addresses and the length and the type of the 

is connection can be extracted only from the initial CC data, 
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transferred across the packet switched GSM or UMTS networks. 
This is mostly due to (historical) technical reasons. 

In particular, the field of the invention is related to a handover of a 
5 Lawful Interception (LI) data from LI entities, e.g. nodes that 

support LI Delivery Function (DF) and LI Mediation Function (MF), 
to a Law Enforcement Monitoring Facility (LEMF) of a Law 
Enforcement Agency (LEA). Such network entities are capable of 
exchanging LI target's data, such as Contents of Communication 
10 (CC), and Interception Related Information (IRI) through logical 
connections, such as Handover Interface port 2 (HI2) and 
Handover Interface port 3 (HI3). DF and MF for HI2 port 
(DF2/MF2) are. logically separated from DF and MF for HI3 
(DF3/MF3). 

15 

In the following, the structure regarding handover of Lawful 
Interception data is described in more detail by referring to the 
respective 3GPP specification (TS 33.108v5.1.0). 

20 A functional block diagram showing the handover interface HI is 
illustrated in Fig. 1. The handover interface HI comprises three 
Handover Interface ports HI1 , HI2 and HI3. HI1 serves to convey 
administrative information. The links for such administrative 
information are indicated by dotted arrows. HI1 is connected to 

25 the NWO/AccessProvider/SvP's (Network Operator/Access 
Provider/Service Provider's) administrative function, which is 
indicated by ADMF in the figure. The ADMF controls functions of 
the IRI mediation function (IRI MF) and the CC mediation function 
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(CC MF). In addition, the ADMF has access to the network 
internal functions via an Internal Network Interface (INI). These 
functions are indicated in the figure by the inner circle, whereas 
the outer circle indicates the whole NWO/AccessProvider/SvP's 
5 domain. 

HI2 serves to convey IRI (intercept related information) which is 
provided from an Internal Interception Function (IIF) of the 
network via the INI and the IRI MF. HI3 serves to convey CC 
10 (Content of Communication) which is provided from the IIF via the 
INI and the CC MF. 

The LEA domain is indicated by the thick line on the right side of 
the figure. In particular, the LEMF as a part of the LEA domain 
15 receives IRI and CC via HI2 and HI3, respectively, and also 
handles the administrative information via HI1 . 

The LI target is a communication entity, such as IMSI, MSISDN, 
IMEI or IP interface, which may be used by a suspect. 

20 

The access point is e.g. for a corporate network that offers its 
employees Intranet services. It can also be an ISP (Internet 
Service Provider) service point that offers Internet services. 

25 However, presently the IRI events do not contain information 
about the service used by a user, which, nevertheless, may be 
important when observing a target. 
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Heretofore, this was only possible by analysing the CC data. 
However, sometimes it is impossible to analyse the CC data and 
more often the analysis results are too late when obtained. 

5 In addition, LEA may be entitled to receive only IRI data 

associated with a given target That is, in some cases the LEA is 
not entitled to receive CC data such that the used service or other 
information may be obtained. 

10 In such case, i.e., when the LEA is only entitled to receive IRI 
data, the LEA will be informed once the target activates a 
telecommunication service, such as activating a PDP context via 
the Packet Switched (PS) domain of a GSM/UMTS system. 
However, the LEA may still wish to know how actively the target is 

15 using services via the PS domain. For instance, how often the 
target sends/receives messages (SMS, email, etc.). 

This kind of functionality is not supported by current HI 
specifications. 

20 

That is, presently it is not possible to obtain additional information 
as service information or traffic information without examining the 
CC data. 

25 Thus, as described above, heretofore it is only possible to obtain 
general IRI events (sent via HI2) or detailed CC data (sent via 
HI3). 
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This is in particular disadvantageous in a case in which some 
more detailed information is required as can be given by the 
currently defined IRI events, but obtaining of detailed CC data is 
not possible or permitted. 

Therefore, the prior art has the drawback that no flexible handling 
of connection information is possible. 

Summary of the invention 
10 Thus, the object underlying the present invention resides in 

solving the above-described problems such that an interception 
can be handled more flexibly and it is possible to obtain more 
information about a target even when the payload of intercepted 
data packets may not be examined, 

is 

According to a first aspect of the invention, this object is solved by 
a method for handling connection information in a communication 
network. The method includes the steps intercepting a data 
packet sent from/to a target, composing a header for the 
20 intercepted data packet, and sending the composed header to a 
monitoring entity. 

Alternatively, the object is solved by a system for handling 
connection information in a communication network. The system 
25 includes an intercepting means for intercepting a data packet sent 
from/to a target, a composing means for composing a header of 
the intercepted data packet, and a sending means for sending the 
composed header to a monitoring entity. 



6 



WO 2004/047478 PCT/IB2003/005125 



In this way, only the composed header is transmitted to the 
monitoring entity (e.g., LEA), without sending the actual content of 
the data packet, i.fe., the payload. 

5 

The headers of a data packet contain more information than the 
heretofore defined IRI events. Hence, a more flexible handling of 
the connection information is possible, even if accessing of the 
payload of the data packets is not possible or permitted. 

10 

Furthermore, the header may be composed and the payload of 
the intercepted data packet may be discarded. That is, the 
intercepted data packet may be conveyed up to a point to which 
such a transport is allowed (e.g., a delivery function/mediation 
is function (DF/MF)). Then, the payload is simply discarded, i.e., 
deleted, such that the composed headers may be easily 
transmitted to the monitoring entity. 

The composed header may be sent to the monitoring entity via an 
20 interface dedicated to sending contents of communication 

messages. The interface may be the HI3 interface, as defined in 
the specification 3GPP TS 33.1 08v5.1 .0. 

Alternatively, the composed header may be sent to the monitoring 
25 entity via an interface dedicated to sending interception related 
information messages. The interface may be the HI2 interface, as 
defined in the specification 3GPP TS 33.108v5.1.0. 
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The intercepted data packet may be transmitted via a X interface. 
In this case, upon intercepting a X contents of communication 
(CC) message is assembled by adding a X interface header to the 
intercepted data packet, and upon composing the header, the 
5 intercepted data packet may be extracted from the X contents of 
communication (CC) message, a HI contents of communication 
header may be created and the intercepted data packet may be 
discarded- That is, the HI CC header forms the HI CC message. 
Thus, the case can be handled in which a complete data packet is 
10 to be sent via the X interface, but is not to be sent via the HI 
interface. 

The X interface in question may be a X3 interface, and the HI 
interface may be a H 13 interface. 

15 

The composed header may be included in an interception related 
information (IRI) message and sent over a HI2 interface to the 
monitoring entity. 

20 Moreover, a frequency of services used by the intercepted target 
may be examined by the monitoring entity based on the received 
composed headers. For example, it may be examined, how often 
a particular service like e-mail or a service offered by a specific 
service provider is used. 

25 

Moreover, an user data header (or a plurality of user data 
headers) may be extracted from the intercepted data packet and 
added to the composed header to be sent to the monitoring entity. 
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That is, when composing the header (before e.g., discarding the 
payload), it can be looked into the packet whether some specific 
information (e.g., IP addresses, special service indications and the 
5 like) are included in the data packet, i.e., in the user data headers 
of the actual IP packet sent over the internet, for example. Such a 
user data header may be an IP header, an UDP/TCP header or 
upper layer headers inserted by the user's application. In this way, 
the specific information derivable from the headers may be 
10 included into the header to be sent to the monitoring entity. 

Thus, the flexibility of handling the interception information can be 
further increased, since in addition particular items can be 
gathered from the data packets without that it would be necessary 
is to sent the whole data packet. 

According to a further aspect of the invention, the above object is 
solved by a method for handling connection information in a 
communication network. The method includes intercepting data 
20 packets sent from/to a target, examining the intercepted data 
packets with respect to specific information, determining whether 
an predetermined event with respect to the specific information 
has occurred, and if the predetermined event has occurred, 
sending a corresponding message to a monitoring entity. 

25 

The above object is also solved by a system for handling 
connection information in a communication network. The system 
includes an intercepting unit for intercepting data packets sent 
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from/to a target, and a controlling unit adapted to examine the 
intercepted data packets with respect to specific information, to 
determine whether an predetermined event with respect to the 
specific information has occurred, and to send, if the 
5 predetermined event has occurred, a corresponding message to a 
monitoring, entity. 

In this way, the intercepted data packets are examined for specific 
information, which may be service information or traffic 
10 information. When a predetermined event (e.g., exceeding a 
threshold in case of traffic information or changing of a service) 
occurs, the message is sent. 

Thus, it is possible to look for specific information which are 
is interesting for a monitoring entity (e.g., LEA)- Hence, it is not 
necessary to examine whole intercepted user data packets 
(including the payload or actual data) in order to obtain the 
specific information in the monitoring entity, which might even not 
be possible when the monitoring entity is not permitted to look at 
20 the content of the data packets. 

Hence, a more flexible handling of connection information in a 
communication network is possible. 

25 In addition, it is possible to reduce the traffic load between the 
intercepting network node and the monitoring entity since it is not 
necessary to forward the whole data packets. Moreover, it is not 
necessary to send one event for each data packet. 
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The specific information may contain service information, and the 
predetermined event may be the use of a new service. That is, in 
case the target starts using a new service (either on starting a 
5 communication session or on changing the service during a 
session), a message is sent to the monitoring entity. 

Alternatively, the specific information may contain traffic 
information, and the predetermined event may be exceeding a 
10 predefined threshold of the amount of traffic. That is, in case the 
amount of traffic caused by the target exceeds the threshold, a 
corresponding message is sent to the monitoring entity. 

The predefined event can be a timer expiration when e.g. traffic 
is information needs to be reported once an hour. 

In all cases, only the information interesting for the monitoring 
entity is actually transmitted to the monitoring entity. That is, if the 
monitoring entity is only interested in the services used by the 
20 target or which amount of traffic is caused by the target, it is not 
necessary to forward all intercepted packets to the monitoring 
entity. This reduces the operation load and traffic load within the 
network nodes included in the interception. 

25 The message sent to the monitoring entity may be sent via an 
interface dedicated to sending interception related information. 
For example, this interface may be a HI2 interface. 
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The message to be sent to the monitoring entity may form a 
specific interception related information (IRI) event That is, by 
defining such an IRI event, the message can be handled together 
with other IRI events already handled in interception, 

5 

Moreover, headers of an intercepted data packet may be 
extracted, the extracted header may be included into the message 
to be sent to the monitoring entity. In this way, the contents of 
communication (CC) header may be included in an IRI message, 
10 which is forwarded via a different interface (namely the HI2 

interface) instead of sending it via the interface dedicated to CC 
data (i.e., HI3 interface). Hence, handling of the interception 
information can be more flexible. 

is The examination of intercepted data packets with respect to 

specific information may be performed by examining the extracted 
headers. That is, if it is known that the header contains the 
specific information (e.g., some service indication), only the 
extracted header is examined such that an examination of the 

20 payload is not necessary. In this way, the operation load can be 
reduced. 

The examining may be performed by a packet lookup function of a 
network node (e.g., GSN). Thus, the traffic and the operation load 
25 on the sending means (e.g., DF2) may be reduced. 

Alternatively, the intercepted packets may be delivered from a 
contents of communication (CC) duplicator function to a delivery 
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function (e.g., DF2) such that the examining may be performed by 
the delivery function. In this way, the operation load on the 
network node (e;g., GSN) may be reduced. 

5 A means for performing the interception may be a contents of 
communication duplicator implementation of a network node. A 
means for performing the composing the headers may be a 
delivery function (DF) and/or mediation function (MF) at a 
handover interface (HI). Also, a means for controlling the 
10 extraction and creation the message indicating a predetermined 
event, and/or a means for sending the data to the monitoring 
entity (which may be LEA) may be the delivery function (DF) 
and/or mediation function (MF) of the handover interface. 

is In addition, the invention proposes a method for handling 

connection information in a communication network. The method 
comprises: accessing a subscriber specific database of a target 
within a serving network node, extracting information from the 
subscriber specific database with respect to specific informatidn, 

20 and sending the extracted information to a monitoring entity. 

The subscriber specific database may be a Charging Data Record 
(CDR) of the target. In this way, an already existing database can 
be utilized to obtain information about a target. Thus, it is not 
25 required to perform intercepting of all data packets of the target. 

The specific information may comprise exchanged data volume 
and/or duration of the connection. 
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Brief description of the drawings 

Fig. 1 shows the principle of interception and in particular a LI 
5 Handover Interface HI, 

Fig. 2 shows a flow chart illustrating a procedure according to a 
first embodiment of the invention, 

10 Fig.3(a) to 3(d') illustrate different formats of headers according to 
the first embodiment, 

Fig. 4 illustrates a procedure of creating a PDP context related IRI 
event, 

15 

Fig. 5 shows a procedure of creating a Service Changed IRI Event 
according to a second embodiment of the invention, 

Fig. 6 illustrates signal flows according to the invention used in the 
20 first and second embodiments and modifications thereof by 
referring to eight cases 1 to 8, 

Fig. 7(a) to 7(d) show different data formats used in the cases 1 
and 2, 

25 

Fig. 8 illustrates cases 1 to 4 in which the LEMF receives IRI 
events, and 
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Fig. 9 illustrates cases 5 to 9, in which the LEMF receives CC 
header information. 



5 Description of preferred embodiments 

In the following, preferred embodiments are described by referring 
to the enclosed drawings. 

Before describing the embodiments in detail, in the following the 
10 used terms and definition are listed: 

Access point (AP): point of entry or means of entry to a circuit. In 
general packet radio service (GPRS), an interface between the 
GPRS backbone network and external packet data networks. 

15 

Access provider: e.g. the NWO that makes accessing possible. 

CC message: contents of communication (CC) encapsulated by 
interface specific CC header. System employs X3 interface CC 
20 header and HI3 CC header. 

Communication: Information transfer according to agreed 
conventions. 

25 Content of communication (CC): information exchanged between 
two or more users of a telecommunications service, excluding 
intercept related information. This includes information which may, 
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as part of some telecommunications service, be stored by one 
user for subsequent retrieval by another. 

Handover interface (HI): physical and logical interface across 
5 which the interception measures are requested from network 
operator / access provider / service provider, and the results of 
interception are delivered from a network operator / access 
provider / service provider to a law enforcement monitoring facility. 

10 Identity: technical label which may represent the origin or 

destination of any telecommunications traffic, as a rule clearly 
identified by a physical telecommunications identity number (such 
as a telephone number) or the logical or virtual 
telecommunications identity number (such as a personal number) 

15 which the subscriber can assign to a physical access on a caser 
by-case basis. 

Interception: action (based on the law), performed by an network 
operator / access provider / service provider, of making available 
20 certain information and providing that information to a law 
enforcement monitoring facility. 

Intercept related information (IRI): collection of information or data 
associated with telecommunication services involving the target 
25 identity, specifically communication associated information or data 
(e.g. unsuccessful communication attempts), service associated 
information or data (e.g. service profile management by 
subscriber) and location information. 
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Interception subject: person or persons, specified in a lawful 
authorization, whose telecommunications are to be intercepted. 

5 Law Enforcement Agency (LEA): organization authorized by a 
lawful authorization based on a national law to request 
interception measures and to receive the results of 
telecommunications interceptions. 

10 Law Enforcement Monitoring Facility (LEMF): law enforcement 
facility designated as the transmission destination for the results 
of interception relating to a particular interception subject. 

Lawful authorization: permission granted to a LEA under certain 
is conditions to intercept specified telecommunications and requiring 
co-operation from a network operator / access provider / service 
provider. Typically this refers to a warrant or order issued by a 
lawfully authorized body. 

20 Lawful Interception (LI): see interception. 

Mediation device: equipment, which realizes the mediation 
function. 

25 Mediation Function (MF): mechanism which passes information 
between a network operator, an access provider or service 
provider and a handover interface, and information between the 
internal network interface and the handover interface. 
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Network operator: operator of a public telecommunications 
infrastructure which permits the conveyance of signals between 
defined network termination points by wire, by microwave, by 
5 optical means or by other electromagnetic means. 

Protocol data unit (PDU): information unit passed between peer 
entities. 

10 Result of interception: information relating to a target service, 
including the content of communication and intercept related 
information, which is passed by a network operator, an access 
provider or a service provider to a law enforcement agency. 
Intercept related information shall be provided whether or not call 

15 activity is taking place. 

Service information: information used by the telecommunications 
infrastructure in the establishment and operation of a network 
related service or services. The information may be established by 
20 a network operator, an access provider, a service provider or a 
network user. 

Service provider (SvP): natural or legal person providing one or 
more public telecommunications services whose provision 
25 consists wholly or partly in the transmission and routing of signals 
on a telecommunications network. A service provider needs not 
necessarily run his own network. 
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SMS: Short Message Service gives the ability to send character 
messages to phones. SMS messages can be MO (mobile 
originate) or MT(mobile terminate). 

5 Target identity: technical identity (e.g. the interception's subject 
directory number), which uniquely identifies a target of 
interception. One target may have one or several target identities. 

Target service: telecommunications service associated with an 
10 interception subject and usually specified in a lawful authorization 
for interception. 

Telecommunications: any transfer of signs, signals, writing 
images, sounds, data or intelligence of any nature transmitted in 
is whole or in part by a wire, radio, electromagnetic, photoelectronic 
or photo-optical system. 

X-interface: Interface between intercepting GSN and DF/MF. A 
detailed X-interface definition can be found in specification 3GPP 
20 TS33.107v5.4.0 

In addition, in the following abbreviations are also used in this 
description: 

25 

ADMF Administration Function (controls intercepting 

GSN and DF/MF) 
CGI Cell Global Identity 
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DF Delivery Function 

DF2 Delivery Function for HI2 port 

DF3 Delivery Function for HI3 port 

ftp File Transfer Protocol 
5 GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

GSN GPRS Support Node, SGSN or GGSN 

GTP GPRS Tunnel Protocol 

10 HI1 Handover Interface Port 1 (for Administrative 
Information) 

HI2 Handover Interface Port 2 (for Intercept 

Related Information) 

HI3 Handover Interface Port 3 (for Content of 

is Communication) 

HTTP HyperText Transfer Protocol 

I A Interception Area 

IE Information Element 

IMEI International Mobile station Equipment Identity 

20 IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

MF2 Mediation Function for HI2 port 

MF3 Mediation Function for HI3 port 

MS Mobile Station 

25 MSISDN Mobile Subscriber ISDN Number 

NSAPI Network layer Service Access Point Identifier 

NWO Network Operator 

PDP Packet Data Protocol 
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PLMN Public land mobile network 

SGSN Serving GPRS Support Node 

TEID Tunnel Endpoint Identifier 

UMTS Universal Mobile Telecommunication System 

5 URL Uniform Resource Locator 

X2 Interface between intercepting node and DF2/MF2. 

X3 Interface between intercepting node and DF3/MF3 



First embodiment 
10 In the following, a first embodiment of the invention is described. 
Basically, according to the first embodiment a header is 
composed from an intercepted data packet, and only this 
composed header is sent to the LEMF (i.e., the monitoring entity). 

is Thus, according to this first embodiment, the new type of IRI data 
is sent via the HI3 interface. Namely, a CC header without the 
target's data is sent via the HI3 interface. This procedure 
according to the first embodiment is described in detail in the 
following. 

20 

As described in the introductory part, there may be cases in which 
the LEA is only entitled to receive IRI data associated with a given 
target and not corresponding CC data. In such case, the LEMF 
will be informed once the target activates a telecommunication 
25 service, such as activating a PDP context via the Packet Switched 
(PS) domain of a GSM/UMTS system. However, the LEA may still 
wish to know how actively the target is using services via the PS 
domain, for instance, how often the target sends/receives 
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messages (SMS, email, etc.). According to the prior art, this kind 
of functionality Is not supported by current HI specifications. 

Thus, according to the first embodiment, it is possible to provide a 
5 LEA with the data on how often a target is using 

telecommunication services via PS domain of the GSM/UMTS, 
system, when LEA is entitled to receive only IRI data associated 
with a given target. 

10 In particular, the first embodiment provides a possibility to a LEMF 
to monitor the activity of the target in the following way. In case 
authorization for only the IRI interception has been granted to a 
LEA, LEMF would need to receive a special type of the IRI data, 
which would provide for the estimation of the data volume 

15 exchanged by target, and the duration and intensity of the data 
exchange session(s). 

Such type of IRI has not been defined according to the prior art. 
The reason for this was that only DF3/MF3 may obtain the 
20 relevant IRI data from CC, without sending the actual CC data to 
LEMF. However, HI3 definition allowed only for the CC delivery to 
LEMF, and not the IRI delivery. 

According to the first embodiment, this problem is solved by 
25 modifying the definition of the HI3 port. In the modified HI3 
definition a new IRI type and its usage is defined. 
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The process according to the first embodiment is described in the 
following by referring to the flowchart shown in Fig. 2. The process 
starts when the ADMF instructs a GSN to intercept (copy) target's 
data, which makes up the initial CC packet (step S1 ). The GSN 
5 assembles an X3-interface CC message by adding an X3 

interface header to the copy of the target's initial CC data packet 
(step S2). The X3 interface CC message is sent via the X- 
interface (i.e., in this case via the X3 interface) to the DF3/MF3. 

10 When, the DF3/MF3 receives X3 interface CC message, the 
DF3/MF3 extracts the initial CC data packet from the message 
(step S3), and creates a HI3 CC header. Note, that the H 13 CC 
header would not necessarily be identical to the X3 CC header. 
For instance, those headers may be encoded differently. After 

15 that, according to the prior art the DF3/MF3 encapsulate the initial 
CC data packet by HI3 CC header, thus forming an HI3 CC 
message. However, according to the present embodiment, the 
DF3/MF3 discards the initial CC data packet (step S4), and sends 
only the HI3 CC header to LEMF (step S5). 

20 

Discarding of the initial CC data packet may be instructed by the 
ADMF. 

The HI3 CC header is actually the new type of the IRI. That is, 
25 LEMF receives only IRI. This is correct, because LEA was entitled 
to receive only IRI. 
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It is noted that according to the first embodiment, the ADMF would 
instruct the GSN to execute the IRI-only interception. Rather, the 
ADMF would instruct the DF/MF to do so. Namely, according to 
the prior art, once the DF3/MF3 receives X3 interface CC 
5 message, the DF3/MF3 would encapsulate the initial CC data . 
packet by HI3 CC header, thus forming an HI3 CC message 
which would be sent to the LEMF. 

However, according to the first embodiment, the initial CC data 
10 packet (i.e., the payload) is discarded. Thus, the CC data is not 
visible to LEMF. 

According to a modification of the first embodiment, DF3/MF3 may 
optionally in addition look into the IP header of the targets CC 

15 data packet. In such a solution, DF3/MF3 would extract additional 
IRI data, relevant for LEA, such as IP addresses. Therefore, HI3 
CC header would be amended by this additional data, which 
would make the HI3 IRI much more informative. This optional 
functionality would require extra processing efforts by the 

20 DF3/MF3 implementation. 

In the following, the headers used according to the first 
embodiment are described in more detail by referring to Figs. 3(a) 
to 3(c). Figures illustrate layer 3 and upper layer headers only. 

25 

Fig. 3(a) illustrates the format in which GPRS or PS domain 
handle the user's (target's) data, which is sent across the Gn 
interface in GPRS. As shown, the format comprises a user data 
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part which is the actual IP packet sent over the Internet, and PS 
domain specific headers. The user data part comprises the actual 
data (i.e., the payload) and several headers #4 to #6. An IP 
header #4 indicates the destination address, which is in this case 
5 the IP address of a user. An UDP/TCP header #5 indicates the. 
destination port, which is in this case the number of the user 
application. Upper layer headers #6 are inserted by the user 
application. The PS domain specific headers comprises an IP 
header #1 indicating the destination address of a GSN or RNC 
10 (here, the IP address of the SGSN), a TCP/UDP header #2 
indication the destination port (here, the port number at the 
SGSN) and an GTP header #3 indicating a TEID (here the TEID 
requested by the SGSN). 

is According to the first embodiment, the GSN may optionally be 
instructed to look into the #4 header, i.e., into the IP header. 

Fig. 3(b) illustrates the format in which the intercepting GSN 
sends the CC message across the X3 interface to DF3. As also 
20 described above, this message is assembled by adding a X3 
interface CC header #3(X3) to the user data part and by adding 
an IP header #1(X3) indicating the IP address of the DF3 as the 
destination address and a TCP/UDP header #2(X3) indicating the 
port number at the DF3 as the destination port. 

Fig. 3(c) illustrates the format in which the DF3 sends the new 
type of IRI across the HI3 port to LEMF. This message is 
assembled by adding an IP header #1(HI3) indicating the IP 

25 
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address of the LEMF as the destination address and a TCP/UDP 
header #2(HI3) indicating the port number at the LEMF as the 
destination port to the HI3 interface CC header #3(HI3). Only the 
thus assembled HI3 CC message (consisting only of the headers 
5 #1(1-113), #2(HI3) and #3(HI3) is sent to the LEMF. 

As an alternative to the first embodiment, the DF3 may also 
include some of the user data headers #4 to #6 into the message 
sent to the LEMF. The corresponding format is shown in Fig. 3(d). 
10 In particular, the IP header #4 of the target could be included. 
Moreover, the upper layer headers #6 which are inserted by the 
target's application could be included since in this case the LEMF 
could monitor the details of kinds of services used by the target. 

15 Therefore, according to the first embodiment, the DF3 is 

instructed to send either none, or optionally only the IP header 
(#4) to LEMF, and to discard the rest of the CC message which 
was sent over the X3 interface to the DF3. That is, of the user 
data part only the IP header is sent to the LEMF via the HI3 port. 

20 

Summarizing, according to the first embodiment, a simple solution 
is provided. Normally, once a DF3/MF3 receives the X3 interface 
CC message shown in Fig. 3(b), DF3/MF3 shall replace the X3 
header by a HI3 header, add respective TCP/UDP and IP headers 
25 to each initial CC data packet and send the aggregated data 

packet (not shown) to an LEMF. However, in case only IRI may be 
sent to the LEMF (i.e., a look into the actual data is not permitted), 
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the DF3/MF3 shall compose and send only a CC header to the 
LEMF (i.e., the message shown in Fig. 3(c)). 

In the following, a preferred implementation of the present first 
5 embodiment is described by referring to the respective 3GPP . 
specification (TS 33.108v5.1.0). In particular, the relevant parts of 
the specification are described in the following, and also the 
necessary changes of them are emphasized. In particular, service 
aspects (stage 2) and protocol level (stage 3) are described. 
10 ' . 

According to the preferred implementation of the first embodiment, 
formats of IRI and CC sent across the HI2 and HI3 interfaces may 
differ from X-interface counterparts. Hence, in principle it is 
possible to fine tune IRI and CC definitions for HI interfaces. This, 
15 in turn may require to fine tune the definitions of the HI2 and HI3. 

Thus, according to the preferred implementation of the first 
embodiment, a new IRI type is defined. This special type of IRI 
shall be sent across the HI3 port. HI3 port definition has been 
20 modified. 

Thus a definition of a new IRI type is introduced. This special type 
of IRI shall be sent across the HI3 port. Therefore, a modified 
version of the HI3 port definition has been provided. 

25 

First, an overview of the handover interface is given. The structure 
is based on that shown in Fig. 1 . 
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The generic handover interface adopts a three port structure such 
that administrative information (HI1), intercept related information 
(IRI), and the content of communication (CC) are logically 
separated. ' 

5 

HI2 shall transport the IRI. 

HI3 shall transport the CC, and, in particular according to the first 
embodiment, optionally a special type of IRI. 

10 

Fig. 1 shows a block diagram with the relevant entities for Lawful 
Interception. 

The outer circle represents the NWO/AccessProvider/SvP's 
15 domain with respect to lawful interception. It contains the network 
internal functions, the internal network interface (INI), the 
administration function and the mediation functions for IRI and 
CC. The inner circle contains the internal functions of the network 
(e.g. switching, routing, handling of the communication process). 
20 Within the network internal function the results of interception (i.e., 
IRI and CC) are generated in the Internal Interception Function 
(IIF). 

The IIF provides the Content of Communication (CC) and the 
25 Intercept Related Information (IRI), respectively, at the Internal 
Network Interface (INI). For both kinds of information, mediation 
functions may be used, which provide the final representation of 
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the standardized handover interfaces at the 
NWO/AccessProvider/SvP's domain boundary. 

It is noted that Fig. 1 shows only a reference configuration, with a 
5 logical representation of the entities involved in lawful interception 
and does not mandate separate physical entities. Moreover, the 
mediation functions may be transparent. 

The handover interface port 2 shall transport the IRI from the 
10 NWO/AccessProvider/SvP's I IF to the LEMF. 

The delivery shall be performed via data communication methods 
which are suitable for the network infrastructure and for the kind 
and volume of data to be transmitted. 

15 

The delivery can in principle be made via different types of lower 
communication layers, which should be standard or widely used 
data communication protocols. 

20 The individual IRI parameters shall be coded using ASN.1 and the 
basic encoding rules (BER) (as defined in TS 33.108). The format 
of the parameter's information content shall be based on existing 
telecommunication standards, where possible. 

25 The individual IRI parameters have to be sent to the LEMF at 
least once (if available). The IRI records shall contain information 
available from normal network or service operating procedures. In 
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addition the IRI records shall include information for identification 
and control purposes as specifically required by the HI2 port. 

The I IF is not required to make any attempt to request explicitly 
5 extra information which has not already been supplied by a 
signalling system. 

The port HI3 shall transport the content of the communication 
(CC) of the intercepted telecommunication service to the LEMF. 
10 The content of communication shall be presented as a transparent 
en-clair copy of the information flow during an established, 
frequently bi-directional, communication of the interception 
subject. 

is An appropriate form of HI3 depends upon the service being 
intercepted. According to the first embodiment, as a national 
option HI3 may transport a special type of IRI as well. This type of 
IRI shall be coded using either ASN.1 and the basic encoding 
rules (BER), or TLV, as specified in the following. 

20 

The HI2 and HI3 are logically different interfaces, even though in 
some installations the HI2 and HI3 packet streams might also be 
delivered via a common transmission path from a MF to a LEMF. 
It is possible to correlate HI2 and HI3 packet streams by having 
25 common (referencing) data fields embedded in the IRI and the CC 
packet streams. 
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Thus, in the definition of the IRI for packet domain, as a national 
option, an additional type of IRI may be defined, which contains 
only the CC header. This special type of IRI shall be send across 
the HI3 port. 

5 

Furthermore, the HI3 CC definition has to be changed such that is 
comprises HI3 CC and IRI definition. 

In particular, the CC PDU (Contents of Communication Protocol 
10 Data Unit) has to be redefined such that the payload size is 
defined as including 0 as the length of the payload: 

CC-PDU ::= SEQUENCE 
{ 

15 uUC-header [1] ULIC-header, 

payload [2] OCTET STRING (SIZE (0.. 65535)) 

} 

Namely, for the IRI sent across the HI3, it is possible to either 
20 send only uLIC-header (UMTS LI Correlation Header (ULIC)), or 
uLIC-header with the payload, which has '0' length. The uLIC 
header is the HI3 CC header sent from the DF3/MF3 across the 
HI3 interface port to the LEMF. 

25 The ULIC header has to be defined such that it may represent the 
IRI sent across the HI3. 
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10 



ULIC-header ::= SEQUENCE 
{ 

hi3Domainld 



version 
HID 

correlation-Number 
timeStamp 
sequence-number 
t-PDU-direction 



, [0] OBJECT IDENTIFIER, 
(3GPP HI3 Domain) 
[1] Version, 

[2] Lawfullnterceptionldentifier 

OPTIONAL, 
[3] GPRSCorrelationNumber, 
[4] TimeStamp OPTIONAL, 
[5] INTEGER (0..65535), 
[6]TPDU-direction, 



In the following, the definition of ULIC header is described. The 
is currently used ULIC-header version 1 is defined in ASN.1 and is 
encoded according to BER. It contains the following attributes: 



20 



ULIC header version (version) 
set to version2. 

lawful interception identifier (LIID, optional) 
sending of lawful interception identifier is application 
dependant; it is done according to national requirements. 



25 - correlation number (correlation-Number) 

The correlation number is unique per PDP context and used 
fpr a correlation of CC with IRI and/or a correlation of different 
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IRI records within one PDP context. 

- time stamp (timeStamp, optional), 

sending of time stamp is application dependant; it is done 
5 according to national requirements. 

- sequence number (sequence-number). 

Sequence Number is an increasing sequence number for 
tunneled T-PDUs. Handling of sequence number is 
10 application dependent; it is done according to national 

requirements (e.g. unique sequence number per PDP- 
context). 

- TPDU direction (t-PDU-direction) 

15 indicates the direction of the T-PDU (from the target or to the 

target). 

The ULIC header is followed by a subsequent payload information 
element. Only one information element is allowed in a single 
20 signalling message. 

For IRI sent across HI3 port: 

• Only the ULIC header is sent; 

• The ULIC header may followed by a subsequent payload 
25 information element. In such case, the length of the payload 

information element shall be set to '0\ 
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Moreover, the usage of the FTP has to be modified. Namely, FTP 
shall be used to transfer CC across the HI3 port. As a national 
option, FTP may be used to transfer special type of IRI across the 
HI3 port. In such case, the value of the PayloadLength field in the 
5 CC header shall be set to '0'. 
* i,. 

In addition, a new file type has to be defined for FTP. The current 
file naming method A) defined is 

10 <LIID>_<seq>.<ext> 

LI ID is the lawful interception identifier, which is assigned for each 
target identity related to an interception measure. 

is Seq = integer ranging between [0..2 A 64-1], in ASCII form (not 
exceeding 20 ASCII digits), identifying the sequence number for 
file transfer from this node per a specific target. 

Ext = ASCII integer ranging between [ , T\. ,, 7 n .] (in hex: 
20 31H...37H), identifying the file type. The possible file type codings 
for intercepted data are shown in table C.1 . But for the CC across 
the HI3 interface, only the types "2", "4 n , and "6" are possible. 

According to the first embodiment, the ASCII value "1" shall be 
25 used for the IRI sent across the HI3 port. The following table 
illustrates the possible file types. 
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File types that the LEA may get 


Intercepted data types 


"1" (in binary: 0011 0001) 


IRI 


"2" (in binary: 0011 0010) 


CC(MO) 


"4" (in binary: 0011 0100) 


CC(MT) 


"6" (in binary: 0011 0110) 


CC(MO&MT) 



Thus, the least significant bit that is T in file type 1, is reserved for 
indicating IRI data as created according to the first embodiment. 



5 The remaining bits are not under scope of the present 
embodiment, and a detailed description is omitted here. 
Nevertheless, it is referred to the above-mentioned 3GPP 
specification (TS 33.108v5.1.0). 

10 It is noted that the above detailed description of modifications to 
the 3GPP specification (TS 33.108v5.1.0) are only an example for 
an implementation of the first embodiment. The first embodiment 
can also be implemented in different ways, as long as only the 
header of the intercepted data packet is sent to a monitoring entity 

is (e.g., LEMF), without sending the payload of the intercepted data 
packet. 

Second embodiment 

In the following, a second embodiment of the invention is 
20 described by referring to Figs. 4 and 5. 
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According to the second embodiment, the interception is carried 
out with respect to specific information. An example for such 
specific information can be service information. It is determined 
whether a predetermined event with respect to the specific 
5 information has occurred, and, if the predetermined event has . 
occurred, a corresponding message to a monitoring entity (e.g., 
LEA) is sent. An example for the predetermined event may be the 
use of a new service. That is, it is monitored whether the target to 
be intercepted starts using a new service and/or changes the 
10 service currently used by the target. 

In more detail, according to the second embodiment a new 
service specific PDP Context related information is produced for 
LEA in IRI events. This makes IRI events more useful in criminal 
is investigation, and possibly decreases the amount of CC 

interception as the service information can be obtained already 
from a less heavy IRI interception. 

The user authentication is a difficult problem while studying 
2p message passing in Internet. Criminals use many techniques - 
such as proxies, address translation and anonymous servers - to 
hide their identity while using Internet. Among the tried techniques 
are new mobile data services such as GSM, GPRS and UMTS PS 
domain. Adding destination IP address and the type of connection 
25 (service) to IRI data makes user authentication in some cases 
possible for LEAs. 
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Currently, i.e., according to the prior art, the PDP Context related 
IRI events include PDP Context Activation, Start of interception 
with PDP context active and PDP context deactivation events. 
The following information about the user and his internet actions 
5 are given: 

■ Observed MSISDN 

■ Observed NSAPI 

■ Observed IMSI 
10 ■ Observed IMEI 

■ PDP Address of observed party 

■ Event Type 

■ Event Time 

■ Event Date 

is ■ Correlation number 

■ Access point name 

■ PDP type 

■ CGI 

■ Routing area code 

20 ■ Failed context activation reason 

■ lAs 

The MSISDN, IMSI and IMEI authenticate the mobile subscriber 
and the mobile equipment. The NSAPI identifies the PDP context 
25 in an MS if the subscriber has several simultaneous PDP 
contexts. The IP address reserved for the PDP context at the 
GSM/UMTS PS domain core network side is called PDP Address. 
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Fig. 4 shows an arrangement in which PDP context related 
information is intercepted. 

In detail, the connection between a mobile station MS and an 
5 access point is conveyed via an SGSN and a GGSN. The MS is 
identified by MSISDN, IMSI and IMEI. The PDP context within.the 
connection to the SGSN contains MSISDN (in this example, 
12345), NSAPI, IMSI (here, e.g., 98765), IMEI (e.g., 54321), PDP 
address (e.g., 1.2.3.4) and APN (e.g., ap.corp.com). From the 
10 SGSN and/or the GGSN, the above described PDP context 
related IRI events are extracted. 

As shown in Fig. 4, the data is sent from the PDP address to the 
Access Point. As shown in Fig. 4, currently PDP context related 
15 IRI events contain PDP address and Access Point Name. 

In the following, the procedure according to the second 
embodiment of the invention is described by referring to Fig. 5 
which illustrates the Service level IRI interception according to the 
20 second embodiment. In the figure, the new items introduced by 
the second embodiment are indicated in bold. 

In general, the service can be identified for example by 

25 ■ Destination host name or IP address and the port number (in 
this case IP header and the protocol e.g. UDP or TCP header 
has to be studied): 
■ An ftp connection to a certain host 
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■ A telnet connection to a certain host 

■ An e-mail sending via a certain mail server 

■ A web browsing in a certain http server 

■ A more specific service identification could be (in this case 
5 certain user data headers need to be studied) 

■ An ftp t transfer of certain files 

■ A web browsing in a certain URL 

■ An e-mail sending to a certain recipients 

10 Fig. 5, illustrates the principle according to the second 

embodiment Only the differences to that structure according to 
Fig. 4 are described in the following. 

The GSN nodes (SGSNs and GGSNs) collect the interception 
15 information (IRI and CC) and send it further. According to the 
second embodiment, for each PDP context that is under 
interception the GSNs keep track oh the current service. The 
service can be as simple as a destination host IP address and 
port (e.g., 1.1.1.1:80, as illustrated in Fig. 5), or more complex as 
20 an HTTP URL (e.g., 2.2.2.2:80:www.nn.net, as illustrated in Fig. 
5). The service level that is intercepted is defined when the GSN 
starts the interception of a PDP context. 

Each time a GSN notices that the service has changed, it 
25 generates a Service Changed IRI event (in addition to other PDP 
context related IRI event shown in Fig. 4). In addition to the PDP 
context information the IRI event contains at least the new 
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service, it might also contain the old service for verification 
purposes. 

The GSN has to study only data packets for the PDP contexts 
5 under interception. That is why the performance loss is not 

assumed to be significant. The needed processing capacity also 
depends on the number of the protocol headers that needs to be 
studied: it is light to find out that the user uses http protocol but 
heavier to find out which URL the user connects to. 
10 The ADMF needs to support service level IRI interception 

configuration. This is straightforward to implement The DF has to 
support Service Changed IRI event; the implementation is 
straightforward, too. 

is Thus, according to the second embodiment, it is not necessary to 
study CC data (i.e., the actual data of the user part data as shown 
in Fig. 3(a), for example), which is according to the prior art the 
only way to get service information from the intercepted packets. 
Namely, often the CC data studying is impossible due to the lack 

20 of resources, or unnecessary due to too long delay. Knowing the 
service information as soon as possible is most useful for a LEA 
because in internet tracks seem quickly to disappear. 

Next, the above procedure and some modifications of it are 
25 described by referring to Figs. 6, 7, 8 and 9. Fig. 6 illustrates all 
possible message flows within a network according to the 
invention, i.e., not only that of the first and/or second embodiment 
but also of some modification. The procedures are described by 
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referring to eight cases, i.e., case 1 to case 8, wherein cases 1 
and 2 illustrate the procedure according to the second 
embodiment, cases 7 and 8 illustrate the procedure according to 
the first embodiment, and cases 3 to 6 illustrate some further 
5 modifications of the second embodiment. 

The cases 1 to 8 are also illustrated in Fig. 8 and 9. Fig. 8 
illustrates cases 1 to 4 in which the LEMF receives IRI events, 
that is, the LEMF does not receive a message for each CC 
10 packet. Fig. 9 illustrates cases 5 to 8, in which the LEMF receives 
CC header information, that is, the LEMF receives one message 
per CC packet. Fig. 7 illustrates the different data formats used in 
the cases 1 and 2. 

is As described above, the second embodiment is about to look at 
the CC data in order to find out the used service. That is, a packet 
lookup implementation of the GSN looks up to each packet under 
interception, collects information about ongoing packets and 
sends control messages to DF2 whenever some threshold values 

20 are met. This is illustrated in Fig. 6 by case 1 . That is, service . 
information is sent from the packet lookup implementation to the 
DF2 (case 1), which generates the Service Changed IRI event 
when a new service is used. 

25 The second embodiment can also be extended such that it can 
deal also with traffic measurements as in the first embodiment. 
According to the second embodiment, this means that a new IRI 
event TrafficMeasurement should be generated when the 
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byte/packet count extends a predefined threshold value 
(configured as the subscriber is put under interception) or a 
predefined timer expires. That is, the packet lookup 
implementation of the GSN (as illustrated in Fig. 6 by case 2) is 
5 modified such that it can measure the amount of traffic generated 
by the target to be intercepted (a simple counter will do). 

Such a process is illustrated in Fig. 6 by case 2. That is, traffic 
information is sent from the packet lookup function to the DF2 
10 (case, 2), which generates the TrafficChanged IRI event when the 
threshold is reached or exceeded. 

In the following, the formats of messages used according to the 
second embodiment are described by referring to Figs. 7(a) to 
15 7(d). The use of the formats is correspondingly indicated in Fig. 6 
by referring to the respective figure. 

Fig. 7(a) shows the format of a message sent to the DF2 when a 
predetermined event occurs, in this case, when a service is 
20 changed. The payload of the message comprises X2 interface IRI 
payload of type "service information". The service information is 
obtained by studying user data headers (not user data payload). 

The headers of the message are PS domain specific headers and 
25 comprise an IP header (destination address is IP address of DF2, 
protocol is TCP, UDP, ...), a protocol header (destination port at 
DF2) and an X2 interface IRI header. 
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Fig. 7(b) shows the format of message sent to the DF2 in case 
traffic information are observed. Here, the PS domain specific 
headers are the same as in the format according to Fig. 7(a), and 
only the payload is different. Namely, the payload comprises X2 
5 interface 1RI payload of type "traffic information". The traffic 
information. is obtained, for example, by studying user data 
payload length, as described above. 

Fig. 7(c) shows the format of the message sent to the LEMF via 
10 the HI2 interface. This message is sent when the message shown 
in Fig. 7(a) is received, i.e., when the GSN informs the DF2 that 
the service has changed. 

The payload comprises the HI2 interface IRI payload of type 
is service changed. That is, the IRI ServiceChanged Event is 
incorporated in this payload. 

The message contains the following PS domain specific headers: 
a IP header (destination address is the IP address of the LEMF, 
20 protocol is TCP, UDP etc.), a protocol header (destination port at 
the LEMF) and a HI2 interface IRI header. 

Fig. 7(d) shows the case regarding the traffic measurement, i.e., 
when the threshold value is exceeded and the message shown in 
25 Fig. 7(b) is received by the DF2. The headers of this message are 
the same. However, the payload comprises the HI2 interface IRI 
payload of type traffic measurement. 
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In addition, in order to give a complete overview of the present 
application, Fig. 6 shows also the messages according to the first 
embodiment. These are indicated by cases 7 and 8. 

5 Namely, the user data to be intercepted are supplied to the GSN 
and are in the format as shown in Fig. 3(a). A CC duplicator 
function extracts the CC data and sends it to the DF3. The format 
used here is shown in Fig. 3(b). The CC header shown in Fig. 3(c) 
is then sent to the LEA, as illustrated by case 7 in Figs. 6 and 9. 

10 

According to the first embodiment, the CC headers may in 
addition contain data extracted from the IP header of the target's 
datagram, namely, the upper layers headers, as described above 
in connection with the first embodiment. The corresponding data 
is format used in case 8 is illustrated in Fig. 3(d), according to which 
the message comprises a payload containing the upper layer 
headers. 

In addition, Fig. 6 illustrates modifications of the second 
20 embodiment, wherein some features of the first embodiment are 
combined with the second embodiment. 

In particular, case 3 shows a procedure in which the CC data 
duplicated by the CC duplicator function of the GSN are not sent 
25 to the DF3 but to the DF2. The corresponding data format is 
shown in Fig. 3(b f ). The format is similar to that of Fig. 3(b) with 
the exception that an X2 interface CC header is inserted and the 
IP header comprises the DF2 IP address as destination address 
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and the TCP/UDP header comprises the DF2 port number as the 
destination port. 

In this case, the DF2 is adapted to extract data regarding service 
5 information from the CC data. When a change of service occur$, 
the DF2 creates a ServiceChanged IRI event which is the same 
as that described in connection with case 1 (data format shown in 
Fig- 7(c)). 

10 A similar modification as in case 2 is shown in case 4. That is, the 
DF2 is adapted to extract traffic information and to generate a 
TrafficMeasurement IRI Event upon exceeding a threshold, for 
example. The TrafficMeasurement IRI event is the same as that in 
case 2, and the data format thereof is shown in Fig. 7(d). 

It is noted that in cases 1 to 4 only an IRI event is sent, that is, the 
messages are not sent to the LEMF on reception of every CC 
packet. In detail, in case 1 and 2 the LEMF receives 
ServiceChanged IRI events or TrafficMeasurement IRI events, 

20 respectively, and the procedure for creating these events is 

initiated by the GSN (due to the service information or the traffic 
information). In cases 3 and 4, the LEMF receives the 
ServiceChanged IRI events or the TrafficMeasurement IRI Events, 
but the procedure for creating these events is initiated by the DF2, 

25 since all CC data are forwarded to the DF2 which performs 
monitoring of the CC data. 
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Case 5 shows an example in which the CC header for each 
packet is delivered to the LEMF by using the DF2, instead of DF3 
as described in the first embodiment and in case 7. That is, the 
CC headers cannot only be delivered via DF3 to the LEMF (as 
5 described above with connection to the first embodiment), but 
they can alsp be delivered via DF3. In particular, the CC data are 
received by the DF2 in the data format shown in Fig. 3(b'). From 
these CC data, the DF2 creates a new IRI similar to that 
according to the first embodiment, i.e., case 7. The data format 
10 thereof is shown in Fig. 3(c'), which is logically similar to that 

shown in Fig. 3(c) with the exception that a HI2 port CC header is 
included instead of a HI3 port CC header. It is noted that although 
the data formats are logically similar, the actual formats can be 
different at HI2 and HI3 (they may e.g. use different encoding). 

15 

Case 6 shows the modification that also user data headers are 
included in the message, similar to case 8. In case 6, the data 
format shown in Fig. 3(d') is used which is logically similar to that 
of Fig. 3(d) with the exception that a HI2 port CC header instead 
20 of a HI3 port CC header is used. 

It is noted that in cases 5 to 8 the LEMF receives CC headers for 
each CC packet. In particular, in cases 5 and 6, the LEMF 
receives traffic information (e.g., length) and service information of 
25 each CC packet via DF2. In cases 7 and 8, the LEMF receives 
traffic information (e.g., length) and service information of each 
CC packet via DF3. 
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Thus, according to the above modifications of the first and second 
embodiments (i.e., in cases 3, 4, 5 and 6), also the CC data 
duplicator implementation may be used that first sends all CC 
data to DF2. The DF2 then analyses the data and sends IRI 
5 events accordingly. That is, the DF2 creates the ServiceChanged 
IRI event and/or the TrafficMeasurement IRI event in response to 
the received CC data (cases 3 and 4), or sends the new IRI 
comprising the CC headers (cases 5 and 6). 

10 Third embodiment 

In the embodiments described above, the packets of a target are 
intercepted in order to obtain information with respect to services, 
for example. However, it is also possible to refer to existing 
databases within a serving network node (e.g., GSN) in order to 

15 obtain such information. This process is described in the following 
as a third embodiment. 

In particular, a so-called Charging Data Record (CDR) is provided 
in a GSN, as defined in 3GPP TS 32.21 5v5.1 .0, for example. 

20 GSNs generate and temporarily store CDRs for all customers. 
CDRs can be generated in many ways. Basically, GSNs count 
packets and calculate payload volumes. Among other fields, the 
CDR may contain List of Traffic Data Volumes (exchanged data 
volume) and Duration (duration of the given record) information 

25 elements. 

Thus, in case the information provided by the CDR is sufficient for 
a monitoring entity such as LEMF, only the information of the CDR 
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could be transmitted to the LEMF without the necessity to perform 
an interception of the data packets. For example, the LI unit of a 
GSN can do a simple CDR lookup and send this particular type of 
IRI to LEMF via DF/MF. 

5 

In this way, the handling of the connection information can be very 
easy and simple, since the CDR is provided in the GSN already 
now according to current standards. 

10 According to the invention, the following advantages are achieved: 

■ LEA obtains more useful information in IRI events. 

■ LEA can obtain service more easily because needs not to 
is analyse CC data. 

■ LEA can obtain service more quickly because needs not to 
analyse CC data. 

20 ■ LEA obtains service even if CC interception is not authorised. 

■ Operator needs less often perform CC interception for LEA and 
so improves GSN capacity. 

25 ■ The DF/MF has to transfer less CC data to LEA. 

■ IRI data in circuit switched and packet switched environment is 
more close with each other. 
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The above description and accompanying drawings only illustrate 
the present invention by way of example. In particular, the 
embodiments can be freely combined. For example, the CC 
5 headers may be delivered to the LEMF via DF2 and DF3. In this 
way, the CC headers may be delivered to the LEMF via DF2 or 
DF3 depending on the operation load on DF2 and DF3, for 
example. In addition, CC headers and IRI events may be 
forwarded to the LEMF, such that the LEMF obtains more data. 

10 

Furthermore, the features according to the embodiments can be 
implemented by considering the system architecture. That is, it 
can be considered how the feature is easier to implement or how 
it uses less system process/network capacity. 

The embodiments and their modifications and/or combinations 
may vary within the scope of the attached claims. 
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10 



WHAT IS CLAIMED IS: 

1 . A method for handling connection information in a 
communication network, comprising the steps of: 

intercepting a data packet sent from/to a target (S1), 
composing a header for the intercepted data packet (S4), 



and 



sending the header to a monitoring entity (S5). 



2. The method according to claim 1 , wherein the header is 
composed and the payload of the intercepted data packet is 
discarded. 

15 3. The method according to claim 1 , wherein the composed 
header is sent to the monitoring entity via an interface dedicated 
to sending contents of communication messages. 

4. The method according to claim 1, wherein the composed 
20 header is sent to the monitoring entity via an interface dedicated 

to sending interception related information messages. 

5. The method according to claim 1, wherein the intercepted 
data packet is transmitted via an X interface, and 

25 the intercepting step (S1) comprises the step of 

assembling an X contents of communication message 
by adding an X interface header to the intercepted data 
packet (S2), and 
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the composing step (S4) comprises the steps of 

extracting the intercepted data packet from the X 

contents of communication message (S3), 

creating a HI contents of communication header (S4) 

5 and 

discarding the intercepted data packet. 

6. The method according to claim 5, wherein the X interface is 
a X3 interface, and the HI interface is a HI3 interface. 

10 

7. The method according to claim 5, wherein the composed 
header is included into an interception related information (IRI) 
message and sent over a HI2 interface to the monitoring entity. 

is 8. The method according to claim 1 , wherein the composed 
header forms a specific type of interception related information 
(IRI). 

9. The method according to claim 1 , further comprising the 
20 step of: 

examining the frequency how often services are used by the 
intercepted target based on a plurality of composed headers, this 
step being performed in the monitoring entity after the sending 
step (S5). 

25 

10. The method according to claim 1 , wherein the composing 
step comprises the steps of: 
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extracting an user data header from the intercepted data 
packet, and 

adding the extracted header to the composed header to be 
sent to the monitoring entity. 

5 

11. A method for handling connection information in a 
communication network, comprising the steps of: 

intercepting data packets sent from/to a target, 

examining the intercepted data packets with respect to 
10 specific information, 

determining whether an predetermined event with respect to 
the specific information has occurred, and 

if the predetermined event has occurred, sending a 
corresponding message to a monitoring entity. 

15 

12. The method according to claim 1 1 , wherein the specific 
information contains service information, and the predetermined 
event is the use of a new service. 

20 1 3. The method according to claim 1 1 , wherein the specific 
information contains traffic information, and the predetermined, 
event is exceeding a predefined threshold of the amount of traffic. 

14. The method according to claim 11, wherein the message 
25 sent to the monitoring entity is sent via an interface dedicated to 
sending interception related information. 
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15. The method according to claim 14, wherein the interface is a 
HI2 interface. 

16. The method according to claim 1 1 , wherein the message to 
5 be sent to the monitoring entity forms a specific interception 

related information (IRI) event. 

1 7. The method according to claim 1 1 , further comprising the 
steps of: 

io extracting a header of the intercepted data packet, and 

including the extracted header into the message to be sent 
to the monitoring entity. 

18. The method according to claim 17, wherein the examining 
is step is performed by examining the extracted header with respect 

to specific information. 

1 9. The method according to claim 1 1 , wherein the examining 
step is performed in a packet lookup function of a network node. 

20 

20. The method according to claim 1 1 , wherein the intercepted 
packets are delivered from a contents of communication 
duplicator function of a network node, and the examining step 
is performed in delivery function (DF2). 

25 

21 . A system for handling connection information in a 
communication network, comprising: 
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an intercepting means for intercepting a data packet sent 
from/to a target, 

a composing means for composing a header for the 
intercepted data packet, and 
5 a sending means for sending the composed header to a 

monitoring entity. 

22. The system according to claim 21 , wherein the composing 
means is adapted to compose the header and to discard the 

10 payload of the intercepted data packet. 

23. The system according to claim 21 , wherein the sending 
means is adapted to send the composed header to the monitoring 
entity via an interface dedicated to sending contents of 

is communication messages. 

24. The system according to claim 21 , wherein the sending 
means is adapted to send the composed header to the monitoring 
entity via an interface dedicated to sending interception related 

20 information messages. 

25. The system according to claim 21 , wherein the intercepting 
means is a contents of communication duplication function of a 
network node which is adapted to send the intercepted data 

25 packet via an X interface to the extracting means, wherein 
the intercepting means is adapted to assemble an X 
contents of communication message by adding an X interface 
header to the intercepted data packet, 
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the composing means is adapted to extract the intercepted 
data packet from the X contents of communication message, 
to create a HI contents of communication header and 
to discard the intercepted data packet. 

5 

26. The system according to claim 25, wherein the X interface is 
a X3 interface, and the HI interface is a HI3 interface. 

27. The system according to claim 21 , wherein the sending 
10 means is adapted to include the composed header into an 

interception related information (IRI) message and to send the 
message over a HI2 interface to the monitoring entity. 

28. The system according to claim 21 , wherein the composed 
is header forms a specific type of interception related information 

(IRI). 

29. The system according to claim 21 , wherein the monitoring 
entity is adapted to examine how often services are used by the 

20 intercepted target based on a plurality of composed headers. 

30. The system according to claim 21 , wherein the composing 
means is adapted to extract an user data header from the 
intercepted data packet and to add the extracted header to the 

25 composed header to be sent to the monitoring entity. 

31 . A system for handling connection information in a 
communication network, comprising: 
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an intercepting means for intercepting data packets sent 
from/to a target, and 

a controlling means adapted to examine the intercepted 
data packets with respect to specific information, to determine 
5 whether a predetermined event with respect to the specific 

information has occurred, and to send, if the predetermined event 
has occurred, a corresponding message to a monitoring entity. 

32. The system according to claim 31, wherein the specific 

10 information contains service information, and the predetermined 
event is the use of a new service. 

33. The system according to claim 31 , wherein the specific 
information contains traffic information, and the predetermined 

is event is exceeding a predefined threshold of the amount of traffic, 
the control means being adapted to measure the amount of traffic. 

34. The system according to claim 31 , wherein the control 
means is adapted to send the message sent to the monitoring 

20 entity via an interface dedicated to sending interception related 
information. 

35. The system according to clam 32, wherein the interface is a 
HI2 interface. 

25 

36. The system according to claim 31 , wherein the message to 
be sent to the monitoring entity forms a specific interception 
related information (IRI) event. 
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37. The system according to claim 31 , further comprising: 
an extracting means for extracting a header of the 

intercepted data packet, wherein 
5 the control means is adapted to include the extracted 

header into the message to be sent to the monitoring entity. 

38. The system according to claim 37, wherein control means is 
adapted to examine the intercepted data packets with respect to 

10 specific information by examining the extracted header. 

39. The system according to claim 31 , wherein the examining 
means is a packet lookup function of a network node. 

15 40. The system according to claim 21 or 31 , wherein the 
intercepting means is a contents of communication duplicator 
implementation of a network node. 

41 . The system according to claim 40, wherein the a contents of 
20 communication duplicator function is adapted to deliver the 

intercepted packets to the examining means which is a delivery 
function (DF2). 

42. The system according to claim 21 , wherein the composing 
25 means is a delivery function and/or mediation function of a 

handover interface. 
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43. The system according to claim 21 , wherein the sending 
means is a delivery function and/or mediation function of a 
handover interface. 

5 44. The system according to claim 31 , wherein the control 
means is a delivery function and/or mediation function of a 
handover interface. 

45. A method for handling connection information in a 
10 communication network, comprising the steps of: 

accessing a subscriber specific database of a target within a 
serving network node, 

extracting information from the subscriber specific database 
with respect to specific information, and 
15 sending the extracted information to a monitoring entity. . 

46. The method according to claim 45, wherein the subscriber 
specific database is a Charging Data Record (CDR) of the target. 

20 47. The method according to claim 45, wherein the specific 
information comprise exchanged data volume and/or duration of 
the connection. 

48. A system for handling connection information in a 
25 communication network, comprising: 

an accessing means for accessing a subscriber specific 
database of a target within a serving network node, and 
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a controlling means for extracting information from the 
subscriber specific database with respect to specific information, 
and sending the extracted information to a monitoring entity. 

5 49. The system according to claim 48, wherein the subscriber 
specific database is a Charging Data Record (CDR) of the target. 

50. The system according to claim 48, wherein thespecific 
information comprise exchanged data volume and/or duration of 
10 the connection. 



59 




1/10 



WO 2004/047478 PCT/IB2003/005125 



CM 



CO 



CM 
CO 



8 



3 



CO 




2/10 



WO 2004/047478 



PCT7IB2003/005125 



CD 



CD 



CD 



o 
c 

CD 
CO 

Qj 



03 
CO 

■a 

0) 
CO 



f2 

CO 

a> 

o 
<E 
o 

CD 
CL\ 
CO 

c 

CO 

E 
o 

"O 

2 



CO 

< 



- 8 
© e 

CL CD 

3 CO 
0) 



<D 

"O CD 
CO CO 



ftll 

CL 2 



CD H 
CO _£ 

XJ 
CO 



u 

Q 



CO 

© 

-Q 



CO 

O © 
(Of 

o 

Q 



■C II 

°- to 

Q 



5 



3, 

CO 

Ll 



2 

CO 

1 



c 

£^8 

* a 

Z) -C gj 



CD 

Be 

43 .2 
ii | 

O CL 
Q. CL 

Q 



SI " 

p> CO 

m CD 

.co t- 

■ T3 



8 



CD 
XJ 
CO 
CD 



8 



II 

a. 



O JQ 

s: q- 

O -S5 



L.9: 

CD CO 

C0 Q 
CD ^ 

x: ll 
0- "to 

a 



8 



CD ' Q. 

=> J= g> 



CO 

g> 

LL 



I 

"O 

75 



CD CO O 

x: £ 

u. o a 

DL ^ * 

a o 



CD CO 

.to C- 



8 fe 

CO "D 

\ 8 



8 



< o 
a a- 

P to 



CM & 
Ll W 

H -a 
to * 



3/10 



WO 2004/047478 



PCT/IB2003/005125 



CO 

ri> 

• mm 

LL 



CO 
LL 



CO 



CO 
LL 



o 
o 

,_ 

O a) 

CO flj 
x£ 



£2 
X 

8 



(D ID u 
— I Jj 

a. ii -£ 

DO? 

CL ^ -t» 

P S o 
I— Q Q. 



CO 

X 

CM 



■sg 

CD II 

x: ^ 

n w 
B: Q 



CO 
CO 

CO 



CO 

X 

3* 



o 
o 

o o 
a- -a 
cm <s 

X JZ 



CO ^ 



CD LU 
SZ _J 



a. .. 

Q * 



Z) o 



0 

ii 

3 



a. c 



+-> t* 
HQ 



o 



a. 

LL 
0) II 



to 



to 
to 

CD 



o 
o 

■e _ 

O m 
CO CO 



J2 

CD 

-a 
co 

_^ CD 
m -<= 

§5 
CO 
CO T> 
CL 

£2 8 

X 3 



£2 



u 

CD 
CO 

CD LU w 
r J 

CL II -£ 

Qt | 

5:^ 

o w 5 
H Q aj 



CD 

CO 

CD 



W CO 
-J co 

II 2 

"O 

co -o 
Q co 



CD 

■a S 
o jS 

(0 X5 
Q- u, 

CM ^ 

X 3 



O 
O 

O <D 

CM <0 
— CD 

X J= 



CD ul 

co 

CD HI ^ 
-C -J CD 



co 

CD II 

-C ^ 

n C° 



CM 
X 

£ 



CM 
X 

CM 



CM 
X 

5 



4/10 



WO 2004/047478 



PCT/IB2003/005125 




5/10 



WO 2004/047478 



PCT/IB2003/005125 




in 

LL 



2 




CO 




CD 




CD 





2 






CO 






CD 






CO 








\ 





II 




z 




SD 


£ iL : JL : 


MSI 


co CO Of 


^ 11 



Q 2 
UJQr 

O CO £ ^ r-. 



— < 

22 co 



Q Q 

UJ 111 
CO CO 
UJ 00 CO 

<0 O O 



CO UJ 

11 

Q Q 
LU UJ 

§s 

UJ UJ 
CO CO 
CO CO 

o o 



UJ 

2: 2 



LU 



hfch 



WO 



oi 



2:5 



UJ UJ 

UJ ^ O Q 5 Q. 
>OOJlUQi 
UIO <OZO_i 





2 

O 
O 
CL 
Q 

Cl- 



lO 
CM 



CO 
C\J 



E 
o 
o 



II 

10 

z li co ^ n 
CO S= JL JL 

lilils 



8 

CL 
03 
II 



6/10 



WO 2004/047478 



PCT/IB2003/005125 



13 

o 

■& 



£ 

<D 
T3 
CO 
<D 

-cr 
o 
*E 
o 

8. 

CO 

c 

(0 

E 
o 
•u 

CO 
Cl 



8 *- 

0) a) 

a* 



0) 
_Q 

1 = 



O 
CLj 

CM 
LL 

Q 



u 
a> 
-a 
co 
a) 



CO 



Li- 



's 

o 
Q_ 



CL 

ll 

s | 

c 



£2 
a> 

CO 
CD 



a 

CD 
CL 
CO 

c 

CO 

E 
o 

TJ 

CO 
0- 



8 



8* 

■6*8 



S 



a> 
x> 

n E 

o «= 
cl ct-e 

P Q 



l: 5 
•a H « 

tM 

^ Q 



LL 



•o 

(0 

o 

CL 



£2 

CD 

3 

o 
4= 
*o 

CD 
CL 
CO 

c 

"co 

E 
o 
-o 

CO 



CD 



"2 V 

CO <d 

J9 o) 

* 8 
8 '5 
£ 8 

CD " 



CN 



is 



3 0) 

x — 



CO 



CL 
Q 
3 

CL 
O 
I— 



CD 

E 

O 

CO Qj 
LU 



CD 



03 



LL 



= LU 



CO 

o 
Q. 



o 

s 

Q. 
CO 

c 

'co 

E 
o 

"O 

CO 
CL 



CD 

* 



^ I 

CO 3 

ou co 

_ CO 

o: CD 
^ E 



8 



*t= CO 

c 

CNJ 



ll 



«J CD 

£ ^ 

Csl £ 

x — 



CO 



55 <d 

8 «L E 

5 Q 
CL 

O LU 



T3 

CD CO 
CO 

Soil 

S: LU 



Ll 



8/10 



WO 2004/047478 



LU 



w 0) 
1 g 

8 J! 

(D O 



"8 



J2 .2 

C ±i 



8 



91 S3 c 



CM B C 



c 
E 

e 

(0 
(0 

o 
o 

1 



c 

.is 

& 55 
c « 

si 

C/) 



> 

<D 
U 

LL 



CO 
<D 

CO uu 
O -J 



as 

8 | 



c 

I 

i 

s 

_g 

CM 
LL 

Q 



PCT/IB2003/005125 




1^ 



litl 

$2^ ® cm 

CO LU S 7 LL 



3 



2: 

CO 

CD 



Q 

O 

o 



CO 



CO 



Q 

O 
O 



CO 

o 

a. 



! 



CD 

a 



CO 



CM 

a) 

co 
O 



erf 



CO «^ 

8 40 

a 



AAA 



CD 

(/> 

CO 

o 



^co 



00 



9/10 



WO 2004/047478 



PCT/IB2003/005125 




O 

JZ u. 
0) CO 

<- •> 

_ 

o 



CO 





CO 



CO 

o 

"a. 

ZJ 



8 

> £ a 

«if 

a) o > 



o 

life 



2, 

CO 



5& 

CO 



CO 

o 
"a. 

"D 



o 



CO 



V 



8 

CD 



CO 

X 



CO 




§ 

1- 

s 



CO 



CO 

o 
-a 



O 
O 

.c co 
o£ 

CO Q 

if 

u. 8 $ 



i 

8 



5 y s 



2> 

CO 



co' 



2 



s5L 
co' 



CD 
CD 

CO 

O 



^0 
CO 



>2L 
co' 



CO 

a 



00 
CO 

O 



3 

CO 



cb 

LL 



10/10 



